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REMARKS 

Claims 1 34 arc pending in the present application. In the Office Action mailed June 28, 
2004, the Examiner rejected claims 1-4, 8-9, 20, 22-26, and 31 under 35 U.S.C. §103(a) as being 
unpatentable over Fcnstcmakcr et al. (USP 6,490,684 Bl) in view of Moeller et aL (USP 
6,694,384 Bl). The Exarniner next rejected claims 5-7, 10, and 30 under 35 U.S.C. §1 03(a) as 
being unpatentable over Fenstexnaker ct al., Moeller et ah, and in view of Hubc et al. (USP 
5,442,541). Claims 13, 1 8, and 33 were rejected under 35 U.,S.C. § 103(a) as being unpatentable 
over Fenstemaker et al. in view of Hube et al. Claims 1 1-12, 14-17, 19, and 21 were rejected 
under 35 U.S.C. §1 03(a) as being unpatentable over Fenstemaker et al. Claims 27-29, 32, and 34 
were rejected under 35 U.S.C. § 102(e) as being anticipated by Fenstemaker et al. The Examiner 
also stated that the Information Disclosure Statement filed on May 1 5, 2001 fails to comply with 
37 CFR 1.98(a)(1). 

Information Disclosure Statement 

'The Examiner stated that the TDS filed May 18, 2001, "fails to comply with 37 CFR 
1.98(a)(1), which requires a list of all patents, publications, or other information submitted for 
consideration by the Office." As such, the Examiner stated that the IDS was placed in the 
application file but the Examiner did not consider the IDS. 

Applicant is uncertain why the Examiner found the IDS objectionable. That ts 7 the TDS is 
simply a statement that Applicant was not aware of any patents or publications which Applicant 
considered material to patentability. However, Applicant utilized the opportunity to make the 
Examiner aware of four co-pending patent applications that Applicant believed the Examiner 
might consider relevant to the examination of the instant application. In accordance with 37 CFR 
1.98(a)(23), Applicant provided a listing of the serial numbers of the co-pending applications. 
That is, 37 CFR 1 -98(a)(23) states that a listing must be provided of "all other information or that 
portion which caused to he listed, except that no copy of a U.S. naten t application need be 
included ." (Emphasis added). Therefore, Applicant believes the TDS filed May 18, 2001 to be in 
full compliance all relevant statutes and rules. As such, Applicant respectfully requests full 
consideration of the TDS filed May 18, 2001, in accordance with MPEP rules for handling of a 
properly filed IDS. 
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generated and downloaded to the enablement requesting device, whereby a separate and distinct 
"feature control manager" of database utilizes the passive key and actually performs the 
enablement. 

In summary, the claimed "data script creator," which is configured to generate a "data 
script" is distinct from the "key" taught by Fentsemaker et ah on numerous points. First, as one 
of ordinary skill in the art will recognize and claim 27 makes clear, a data script is not a passive 
set of alphanumeric symbols as in the key of Fentsemaker et aL Second, the data script itself, and 
not some separate "feature control manager," performs the enabling of the inactive application. 
Third, the data script, which actually performs the enabling, is transmitted to the device. In 
contrast, Fentsemaker et aL teaches that the "feature control manager," which actually performs 
the enabling of the inactive feature, is part of the requesting ultrasound device. See Fig. 1 . 

For at least these reasons, claim 27 is patentably distinct from the art of record. As such, 
claims 28-34 are in condition for allowance pursuant to the chain of dependency. However, 
dependent claims 28-34 include subject matter that is both additionally distinguishable from the 
art of record and further illustrative of the distinctions articulated with respect to claim 27. As 
such, Applicant wishes to take the opportunity to highlight some of these additional distinctions. 

For example, with respect to claim 28, the Examiner stated that "Fentsemaker et al. teach 
that wherein the data script creator is further configured to generate a data script specific to at 
least one of a system identifier, an application identifier, a user identifier, and a host identifier 
(Col. 3, Ins. 31 34].'* (Emphasis added). However, Fentsemaker et al. docs not teach any "data 
script" nor one that is specific to al least one of the specifically recited set of criteria. 

The section cited by the Examiner teaches thai "the request preferably comprises 
information identifying the feature to be enabled and the specific ultrasound device." Col. 3, Ins. 
32-34. Fenstemaker et al. teaches that the key be "unique to the ultrasound device" and **to a 
corresponding feature." Col. 4, Ins. 45-48. Therefore, Fenstemaker et al. does not teach that the 
criteria lor generation include "a system identifier, an application identifier, a user identifier, and 
a host identifier." That is, Fentsemaker et aL, at most, teaches two criteria to which the key is 
unique: the desired feature and the specific ultrasound device. See Col. 3, Ins. 32-34. On the 
other hand, claim 28 includes four diff erent criteria that may be considered, the scope of which is 
well beyond that which is taught or suggested within Fentsemaker et al. As such, claim 28 is 
additionally distinguishable, and patentably distinct from, Fentsemaker et al. 
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Re jections Under Section 102(e) 

The Examiner rejected claims 27-29, 32, and 34 as being anticipated by 
Fenstemaker el al Regarding claim 27, the Examiner stated that Fentsemaker ct al. teaches "a 
data script creator designed to generate a data script configured to enable a selected inactive 
application, wherein the data script is further configured to automatically enable the selected 
inactive application only upon initialization of the device [col. 3, lines. 27 37 and col. 4, lines. 1 - 
8].'* However, contrary to the Examiner's position, Fentsemaker et aL fails to teach or suggest 
either a data script creator or a data script because Fentsemaker et al. simply does not teach the 
use of any data script, as claimed. 

It appears that the Examiner concluded that the "key" taught by Fentsemaker et al. is the 
same as a "data script" as called for in claim 27. However, as clearly illustrated by the elements 
of the claim, the "key" taught by Fentsemaker et al. is not equivalent and does not function in a 
manner consistent with the "data script" called for in claim 27. Specifically, within the various 
sections cited by the Examiner, Fentsemaker et al, teaches, "the key is generated by the remote 
source (step 420) and transmitted to the ultrasound device 100." Col. 3, Ins. 34-36. 
Fentsemaker et aL continues by stating that "after the key is either locally or remotely received, 
the disabled feature is enabled with the key (step 320)." CoL 3, Ins. 52-54. To accomplish 
enablement, Fentsemaker etal. teaches that "the feature control manager 130 compares the 
validation information stored in the feature-controlled database 160 with the received key, which 
preferably also is stored in the feature-controlled database 160 (step 520)." Col. 3, Ins. 57- 61. 
Fentsemaker et al. then states that "[i]f the received key is valid, the feature control manager 130 
generates a command to the ultrasound device application 1 10 to enable the use of the feature 
(step 530)." Col. 3, Ins. 61 -64. Therefore, Fentsemaker et al. teaches the use of a passive key "in 
the form of alphanumeric symbols" that is utilized by a separate and distinct "feature control 
manager" in order to compare the key to "validation information" previously stored in a local 
database. Col. 3, Ins. 1-2 and 57- 61. 

On the other hand, claim 27 calls for "a data script creator designed to generate a data 
script configured to enable a selected inactive application." Simply, the data script called for in 
claim 27 is not a passive set of alphanumeric symbols but instead is "configured to enable a 
selected inactive application." That is the data script, which is generated and sent to the device 
requesting enablement, performs the enablement and automatically enables the selected inactive 
application. This is in direct contrast to Fentsemaker et al. which teaches that the key be 
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Regarding claim 32, the Examiner stated that "Fentsemaker et aL teach that wherein the 
data script is further configured to prevent enabling of the selected inactive application." The 
Examiner staled that such is taught in column 4 t lines 1—8, because, in the interpretation of the 
Examiner, "the feature does not get enabled until the system is rebooted" However, the 
Examiner did not address the actual elements of the cited section of the claim. That is, as 
previously described with respect to claim 27, Fentsemaker et al. simply teaches a passive key 
that consists of nothing more than "alphanumeric symbols" and in no way teaches or suggests a 
"data script" that is configured "to prevent enabling of the selected inactive application within the 
medical imaging scanner during device operation." Claim 32 further defines the functions of the 
data script as being specifically configured to take active steps to "prevent" enablement while the 
medical imaging scanner is in operation. On the other hand, Fentsemaker et al. does not teach 
that the key has such capabilities. Rather, Fentsemaker et al. relies upon the previously resident 
"feature control manager," which, as previously shown with respect to claim 27, actually 
performs enablement and controls when enablement occurs. See CoL 3, his. 57-64 and Col. 4 7 
Ins. 1-15. 

Additionally, the section cited by the Examiner does not teach that enablement is 
prevented while the system is in operation but, at most, only teaches that validation occurs at 
power-up . Col. 4, Ins. 1-3. That is, the cited section states, "Preferably, the feature control 
manager 130 automatically attempts to validate every feature each time the ultrasound device 100 
is powered-up," "Alternatively, the validation function can be automatically performed each time 
an ultrasound application 1 10 is asked to perform a feature," and "As another alternative, some 
features can be automatically validated at power-up and other features can be automatically 
validated on a per-need basis," Col 4, Ins. 1-8 (emphasis added). Therefore, Fenstcmaker et al. 
teaches various times when validation of the previously enabled option may be performed, 
wherein one of the times for this validation is a power-up. Fenstcmaker et al. does not teach that 
anything is prevented from happening, enablement or otherwise. 

Furthermore, Fenstcmaker et al. teaches a myriad of validation options which the "feature 
control manager" may implement for enabling but does not teach or suggest that enablement is 
prevented during operation. Rather, Fentsemaker et al. teaches that "the feature control manager 
130 automatically attempts to validate every feature each time the ultrasound device 100 is 
powered up** or that **the validation function can be automatically confirmed each time an 
ultrasound application 1 10 is asked to perform a feature" or "on a per-need basis." Col. 4, Ins. 1- 
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15. The Examiner has mistakenly interpreted a teaching of a litany of possible times when 
validation could occur as a teaching of an exclusive list so that other limes for validation are 
precluded or "prevented." This is an incorrect assumption as Fenstemaker cl al. does not teach or 
suggest prevention at all but merely provides a list of possible verification times. Therefore, 
while Fenstemaker et al. teaches multiple occasions when validation may occur, it docs not teach 
that 4 the data script is further configured to prevent enabling of the selected inactive application 
within the medical imaging scanner during device operation," as called for. Accordingly, claim 
32 is additionally distinguishable from the art of record. 

Additionally, Fenstemaker et al. make explicitly clear that "validation" and "enabling" or 
"initializing" arc not the same. That is, Fenstemaker et al. states, **Next, the feature control 
manager 130 compares the validation information stored in the feature control database 160 with 
the received key, which preferably also is stored in the feature control database 160 (step 520)." 
Col. 3, Ins. 57-61 (emphasis added), Fenstemaker et al. then continues, "If the received key is 
valid, the feature control manager 130 generates a command to the ultrasound device application 
1 10 to enable the use of the feature (step 530)," 61-64 (emphasis added). Therefore, Fenstemaker 
et al. does not teach preventing enablement while the device is in operation. 

Rejections Under §1 03(a) 
The burden of establishing a prima facie case of obviousness fells on the Examiner. 
MPEP §2142. Specifically, to establish a prima facie case of obviousness, the Examiner must 
establish at least three explicit criterion. 

To establish a prima facie case of obviousness, three basic criteria must be met 
First* there must be some suggestion or motivation, either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the 
art, to modify the reference or to combine reference teachings. Second , there 
must be a reasonable expectation of success. Finally, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations, 
MPEP §2143 

The Examiner asserted that Fenstemaker et al. "teach... automatically installing the 
activation key and enabling the inactive option upon initialization of the device [col., 3, lines 52- 
54; coL 4, Hnes 1-8] " However, as previously addressed Fenstemaker et al. does not teach or 
suggest "installing automatically installing the activation key and enabling the inactive option 
upon initialization of the device," as claimed, but instead, in the very section cited by the 
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Examiner, teaches 'the feature control manager 130 automatically attempts to validate every 
feature each time the ultrasound device 100 is powered-up." Col. 4, Ins. 1-3. Therefore, 
Fenstemaker et al. teaches that valid ation of the previously installed key may be performed at 
every power-up. On the other hand, claim I calls for the actual installation of the yet to-be- 
installed key upon initiali zation of the device. 

Additionally, while claim 1 calls for "automatically,,. enabling the inactive option upon 
initialization of the device " Fenstcmaker el al. only teaches that validation of the key occurs at 
power-up. See CoL 4, Ins. 1-3. Fenstemaker et al. make explicitly clear that "validation" and 
"installation" are not the same. That is, Fenstemaker et al. states, "Next, the feature control 
manager 1 30 compares the validation information stored in the feature control database 160 with 
the received key, which preferably also is stored in the feature control database 160 (step 520),** 
Col. 3, Ins. 57-61 (emphasis added). Fenstemaker et al. men continues, "If the received key is 
valid , the feature control manager 130 generates a command to the ultrasound device application 
1 10 to enable the use of the feature (step 530)." Id. Ins. 61-64 (emphasis added). Therefore, 
Fenstemaker et al. does not teach or suggest "automatically... enabling the inactive option upon 
initialization of the device." 

For at least these reasons, Applicant believes claim 1 is patentably distinct from the art of 
record. Further, claims 2-10 arc in condition for allowance pursuant to the chain of dependency. 
However, claims 2-10 include subject matter that is additionally distinguishable from the art of 
record. As such, Applicant will highlight some of the more apparent distinctions. 

Regarding claim 8, the Examiner apparently acknowledged that Fcaistcmaker et al. does 
not teach "determining a host identifier" but stated that such is inherent to the system as to know 
about the remote computer/server.* 1 (Emphasis added). It appears that the Examiner contended 
that the system has "determined" a "host identifier 7 ' simply because the system is aware that a 
remote device exists because such is "inherent" in the art of record. 

The Bxaminer must provide rational or evidence tending to show the asserted inherency. 
See MPEP §2112. Furthermore, "[t]he fact that a certain result or characteristic may occur or be 
present in tbe prior art is not sufficient to establish the inherency of that result or characteristic." 
In re Rijckaert, 9 F.3d 1 53 1 , 1 534, 28 USPQ2d 1 955, 1 957 (Fed. Cir. 1 993); In re Oelrich, 666 
F,2d 578, 581-82, 212 USPQ 323, 326 (CCPA 1981). Simply, in proffering a rejection relying on 
inherency the Examiner must first overcome a heavy burden. 
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The Examiner failed to meet this burden as the only "evidence" provided is not found in 
the art of record. Specifically Applicant respectfully disagrees that "determining a host 
identifier" is "inherent" and submits that when a computer, all having a processor serial number, 
is connected to the internet the other computers on the internet are not immediately aware of the 
unique processor serial number. As such, the Examiner's "evidence" is insufficient to support a 
rejection based on inherency. See MPEP § 2 1 1 2. 

Additionally, claim 8 calls for "determining a system identifier" and 'Identifying a 
modality," which the Examiner concluded were both taught in column 3, lines 31-34 of 
Fenstemaker et ah However, the cited section states, "As described in more detail below, the 
request preferably comprises information identifying the feature to be enabled and the specific 
ultrasound device." CoL 3, Ins- 31-34* Therefore, Fenstemaker et aL teaches a determination of 
only a feature and a specific ultrasound device. While Applicant agrees that determining a 
"specific ultrasound device" may be tantamount to determining a "system identifier," such does 
not teach or suggest "identifying a modality." Tn fact, as Fenstemaker et al. is only concerned 
with ultrasound devices, only one modality is present and, therefore, identifying a modality would 
be unnecessary. Furthermore, Fenstemaker et al. docs not teach or suggest any way in which the 
system could even be extended beyond ultrasound devices. For at least there reasons, Applicant 
believes claim 8 is patentably distinct from the art of record. 

Regarding claim 10, the Examiner provided a detailed analysis of the claim but did not 
address some elements. Specifically, claim 1 0, in part, calls for "dclcnnining if a user status 
includes one of. . ,a non-completion of training requirements." This clement of the claim further 
serves to illustrate the broad nature of the claimed invention. That is, unlike Fenstemaker ct al., 
the centralized facility of the claimed invention can control access to the option based on a wide 
variety of criteria not taught or suggested by Fenstemaker et al. For at least these reasons, claim 
10 is patentably distinct from the art of record. 

Regarding claim 1 1, the Examiner acknowledged that "Fenstemaker et al do not disclose 
about determining a device operation status." Nevertheless, the Examiner concluded that "a 
routineer in the art would know how to determine a device operation status as just by checking 
the status if the device is performing any one of functions in the device or running any application 
program or if the processor is busy." Therefore, the Examiner concluded such would have been 
obvious to "let the device finish the current job." 
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The burden of establishing a prima facie case of obviousness falls on the Examiner. 
MPEP §2142. When prior art references require a selected combination lo render obvious a 
subsequent invention, there must be some reason for the combination other than the hindsight 
gained from the in vention itself, i.e., something in the prior art as a whole must suggest the 
desirability, and thus the obviousness, of making the combination. Uniroyal Inc. v. Rudkin-Wiley 
Corp., 837 F,2d 1044, 5 U.S.P.Q.2d 1434 (fed. Cir. 1988). 

The Examiner did not provide any motivation for the proposed modification beyond a 
purpose not taught or suggested in the art of record but found explicitly stated in the Application. 
See Application, ffl]3 and 7. That is, as previously addressed, Fenstemaker et aL does not teach 
"prevention" of enablement. In fact, nowhere does the art of record teach or suggest a System for 
automatically enabling options that takes the affirmative and proactive step of ''prohibiting" 
enablement when the device is in operation. 

Therefore, since no support tor establishing a prima facie case of obviousness exists 
anywhere in the art of record. It seems that tbe rejection is based on impermissible hindsight and 
cannot be sustained. Accordingly, Applicant believes claims 12-21 are in condition for allowance 
pursuant to the chain of dependency. However, the Examiner misinterpreted some of the 
elements of claims 1 2-21 and Applicant would like to take the opportunity to correct such errors. 

For example, claim 12 calls for the remote processor to be "programmed to automatically 
initialize the at least one inactive software application only upon reboot of the device." The 
Examiner cited column 4, lines 1-8 of Fenstemaker et al. as teaching such but the cited section is 
unsupportive. That is, the cited section states, "Preferably, the feature control manager 130 
automatically attempts to validate every feature each time the ultrasound device 100 is powered- 
up," "Alternatively, the validation function can be automatically performed each time an 
ultrasound application 110 is asked to perform a feature," and "As another alternative, some 
features can be automatically validated at power-up and other features can be automatically 
validated on a per-need basis." CoL 4, Ins. N8. Therefore, Fenstemaker et al. teaches various 
times when validation of the previo usly enabled option may be performed. On the other hand, 
claim 12 calls for the remote process to initialize the inactive option only upon reboot. 

Fenstemaker et aL make explicitly clear that "validation" and "enabling" or ^initializing'' 
arc not the same. That is, Fenstemaker et al. states, "Next, the feature control manager 130 
compares the validatio n information stored in the feature control database 160 with the received 
key, which preferably also is stored in the feature control database 160 (step 520)." Col. 3, Ins. 
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57-61 (emphasis added). Fenstemaker et al. then continues, "If the received key is valid the 
feature control manager 130 generates a command to the ultrasound device application 1 10 to 
enable the use of the feature (step 530)." 61-64 (emphasis added). Accordingly, the art of record 
does not teach or suggest that which is expressly called for in claim 1 2. 

Claim 14 calls for the remote processor to be "programmed to schedule a software 
application initialization in response to instructions Irom the user." The Examiner cited column 
4, lines 16-30 of Fenstemaker ct al. but the section is unsupportive. Specifically, the section 
teaches that an expiration timing for the enabled option may be scheduled but does not teach or 
suggest that the "initialization" may be scheduled- As such, claim 14 is patentably distinct from 
the art of record. 

Regarding claim 16 the Examiner asserted that column 1, lines 38-42 of Fenstemaker et 
al. as teaching that "the medical device includes one of a cardiology device, a computed 
radiology device, a computed tomography device, a magnetic resonance imaging device, an x-ray 
device, an ultrasound device, a nuclear medicine device, and a positron emission tomography 
device." However, as previously address, Fenstemaker et al. is concerned only with ultrasound 
devices and make not teaching or suggest of how to interact with such wide varying and diverse 
modalities. Accordingly, claim 16 is patcatably distinct from the art of record. 

Regarding claim 22, the Examiner asserted that Fenstemaker ct al. teaches the generation 
and transmission of a software script from the centralized facility to the device. However, as 
previously addressed with respect to claim 27, Fenstemaker et al. does not teach or suggest any 
such script designed to enable the inactive option. Rather, Fenstemaker ct al. only generates and 
transmits a passive, alphanumeric key that is received and installed by a "feature control 
manager" resident with the ultrasound device. See Col. 3, Ins. 26-67. Accordingly, as 
Fenstemaker et al. fails to teach or suggest any script, claim 22 is patentably distinct from the art 
of record. 

Therefore, in light of at least the foregoing, Applicant respectfully believes that the 
present application is in condition for allowance. As a result, Applicant respectfully requests 
timely issuance of a Notice of Allowance for claims 1 -34. 
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Applicant appreciates the Examiner's consideration of these Amendments and Remarks 
and cordially invites the Examiner to call the undersigned, should the Examiner consider any 
mailers unresolved. 




jniw@znspatents. com 



Dated: August 23, 2004 

Attorney Docket No.: GEMS8081 ,080 

P.O. ADDRESS: 

Ziolkowski Patent Solutions Group, LLC 
14135 North Cedarburg Road 
Mequon, WI 53097-1416 
262-376-5170 
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